Paket diperiksa sebelum masuk rak.

Paket yang masuk ke gudang tidak selalu benar. Label bisa kabur. Isi bisa tidak sesuai. Ada juga paket yang tampak rapi, tetapi jumlah barangnya tidak masuk akal. Validasi memeriksa semua itu sebelum data dipakai oleh sistem.

Kuka menyerahkan satu paket kepada petugas pemeriksa di pintu gudang. Petugas melihat bentuk paket, mencocokkan labelnya, lalu membaca isi yang dilaporkan.

Jika paket bermasalah, petugas mengirimnya kembali kepada Kuka dengan alasan yang jelas. Jika paket lolos, petugas merapikan label dan kemasannya sebelum menyerahkannya ke rak.

Petugas tidak menunggu sampai paket berada di rak. Pemeriksaan dilakukan di pintu, saat kesalahan masih mudah dikembalikan dan belum mengganggu isi gudang.

Server menerima data dari luar. Data itu belum boleh dipercaya hanya karena datang dari halaman milik kita. Validasi menjaga agar data yang masuk memiliki bentuk, format, rentang, dan makna yang diharapkan.

Tanpa validasi, data buruk dapat berjalan terlalu jauh. Ia bisa melewati controller dan service, lalu gagal ketika database mencoba menyimpannya. Kesalahan yang seharusnya menjadi tanggung jawab pengirim berubah menjadi masalah di dalam server.

Bayangkan Kuka mengirim paket dengan label umur bernilai minus. Petugas yang teliti mengirimnya kembali dengan 400. Kode itu berarti request perlu diperbaiki. Sebaliknya, jika mesin gudang sendiri rusak dan raknya jebol, server mengirim 500. Itu kesalahan internal.

Perbedaan 400 dan 500 penting. Kuka mendapat petunjuk untuk memperbaiki paket pada kasus pertama. Tim pemilik gudang mendapat sinyal untuk mencari kerusakan sistem pada kasus kedua.

Validasi tipe memeriksa bentuk nilai. Angka harus datang sebagai angka. Teks harus datang sebagai teks. Larik harus datang sebagai larik. Kuka tidak bisa mengisi celah bundar dengan paket kotak.

Setelah tipe benar, pemeriksaan bisa melihat aturan lain. Validasi sintaksis memeriksa format, seperti email yang memiliki tanda @. Validasi semantik memeriksa makna, seperti umur yang tidak boleh minus atau tanggal pulang yang tidak boleh mendahului tanggal datang.

Urutannya membantu petugas memberi pesan yang tepat. Jangan memeriksa arti angka sebelum memastikan nilai itu memang angka. Setiap meja dalam pipeline mengerjakan satu tugas, lalu meneruskan paket yang lolos.

Request masuk lewat pintu pemeriksaan. Tipe, format, dan makna dicek berurutan. Jika lolos, data ditransformasi dan dinormalisasi sebelum handler bekerja. Jika gagal, server mengirim 400.

Percobaan 1
POST /paket
umur: -2
400 Bad Request
Percobaan 2
POST /paket
umur: 12
200 OK

Seperti kartu pos, percobaan pertama kembali kepada pengirim karena umur minus tidak masuk akal. Percobaan kedua lolos dan boleh diteruskan ke handler.

• Validasi memeriksa data dari luar sebelum data menyentuh logika penting.
• 400 menunjukkan request buruk dari pengirim.
• 500 menunjukkan masalah di dalam server.
• Validasi tipe memeriksa bentuk nilai, sintaksis memeriksa format, dan semantik memeriksa makna.
• Pipeline menjalankan pemeriksaan dalam urutan yang jelas.
• Transformasi dan normalisasi menyiapkan data yang sudah lolos agar seragam untuk handler.
• Frontend membantu pengguna, tetapi backend tetap harus memeriksa ulang.

1. Kenapa server harus memeriksa request lagi padahal halaman frontend sudah memeriksa?
2. Apa beda 400 dan 500, dan kenapa beda itu penting?
3. Apa beda cek bentuk atau tipe, cek format atau sintaksis, dan cek masuk akal atau semantik?

Versi teknis membahas tempat validasi bekerja, urutan pipeline, dan cara transformasi menjaga data tetap aman sebelum logika bisnis berjalan.

Disinggung sekilas

• Tiga lapisan tempat validasi tinggal
• Siklus hidup request
• Titik eksekusi

Belum dibahas di sini

• Controller beranotasi lengkap